I'm reluctant to add any new field to _modbus struct (even more a free pointer not managed).
Could you explain your use case?

Note that libmodbus will never do anything to that field, except pass it back in the callback. It does not own the contents of that field.

A common scenario in object-oriented languages like C++ or Swift is to wrap library data structures. In this case, I've defined a class MODBUSContext that has a pointer to modbust_t. When the library provides any kind of callback functionality, there needs to be a way for the called function to get at its own context. In my case, my class implements the custom RTS functionality, but to do so, it needs its own context. The only way to get at that context when called back by libmodbus is for libmodbus to keep track of it. I cast a pointer to my object to void*, and when my callback is called, I get that pointer out of the modbus_t struct, cast it back to my class type, and I'm off to the races.

This is a very common and widely-used pattern.

@stephane Does that make sense?

I've added documentation for the new functions.

Hi stephane and JetForMe. Are there any plans to merge that code with master? I haven't found the code from the pull request in the master branch. I have the same issue and the solution provided by JetForMe seems to be reasonable.

I'm reluctant to add any new field to _modbus struct (even more a free pointer not managed). Could you explain your use case?

When I use libgpiod to read/write the custom RTS IO, I need to at least keep track of the chip obtained from gpiod_chip_open, so that I can accurately use this chip in the callback to get the line, and finally perform the IO operation using gpiod_line_set_value.